Systems that support interaction of one system with another system typically employ mechanisms to provide secure session management. Secure session management is a part of many transactional web applications currently in use. In general, interacting systems utilize an exchange of messages across a network in order to perform, for example, Internet shopping, on-line account management, etc. A “client system” usually issues a request for some secured action such as an on-line purchase and a “secure system” usually performs authentication services. Many different types of systems may engage in this type of interaction, including user applications such as a web browser, custom applications, etc.
Secure session management may involve three phases, as illustrated in FIG. 1. In the first phase (step 102), the identity of the user is established through the presentment and validation of a set of credentials. This phase is sometimes called user authentication. Credentials may be an ID and password, an X.509 digital certificate, or any one of different types of information that derives from information that the user knows, or may be derived from various characteristics, such as biometric credentials. Once authentication occurs, the identity of the user is established and this identity may be used by the underlying application system to ensure that the user is handled in an appropriate way. Typically, this includes ensuring that the user has been authorization to perform requested activities, such as on-line purchases. This identity may also be used to ensure correct association with other information related to identity, such as valid financial instruments. Authentication results in the return of a session token from the authenticating system to the client system.
In a second phase of secure session management (step 104), the user is authorized such that the user is granted various levels of access to the various systems in question. The session token is presented with each request from a client system. When a client system wishes to send a message, the client system sends the session token, along with the message, to signify the authenticated identity of the requestor. The session token may be provided in lieu of authentication credentials because the receiving system may recognize the session token and use the session token to retrieve information about the previously authenticated user. The session token may also be used by the receiving system to compare information about the current user's session with previously stored information. Session information may include information about the original credentials presented plus session attributes such as duration, originating system or network, and more. Secure session management involves a system where the client submits the session token with each request, and the receiving system validates the token with each request.
The third phase of session management is session termination (step 106), which may occur programmatically, as by a request from the client system. It may also occur under the control of a security system, which may use duration, inactivity, or other characteristics to determine when a session should end. Upon termination of a session, if the client system subsequently attempts to present the session token that corresponds to the terminated session, an error will occur and the target of the request will reject the request.
Session management on the Internet typically occurs in one of several different ways. As Hypertext Transfer Protocol (“HTTP”) is inherently stateless, it does not automatically afford a mechanism for session management. When a user requests a Uniform Resource Locator (“URL”) from a web browser, there is no standard method for the receiving HTTP server to recognize the user identity or the fact that earlier requests originated from the same client. In order to overcome this deficiency, web applications may use cookies, mangled URLs, hidden form fields, or the like to identify a user. A cookie is a sequence of binary information that a web server may send to a client system, and which the client system sends back to the web server with each subsequent request, assuming the user employs a web browser client with cookie support present and enabled. A web application may inspect the value of cookies, and search for cookies that it previously issued in order to determine that a given web request is from a user who had previously been sent a cookie. Secure session management with cookies typically entails sending a session token in the form of a cookie when a user is authenticated, and then verifying the cookie whenever that user submits a subsequent request. Hidden form fields work in a similar way. The HTML content that is sent to a user contains the session token in a field that is not displayed by the browser. Instead, it is returned to the server when the page request is submitted. With URL mangling, the session token is encoded into the URL of a request.
The provision of session management and authentication capabilities is typically provided by replicating software code across each such business application that requires such functionality such that, for example, a brokerage unit and a banking unit of the same organization each have copies of the same code for authenticating users. However, replication of software code may not utilize resources in an efficient manner. Replication of code often utilizes redundant or disparate systems for the storage of authentication credentials and sessions. Replication of software code may also lead to inefficient and error-prone software, as code in one section of a program may be updated without updating the code in other sections. Replication of software code may also lead to undesirable user experiences. For example, users must remember a large number of distinct IDs and passwords, and login to each business system regardless of having earlier logged into other business systems of the same enterprise. Such instances may occur, for example, when a user has both a credit account and a brokerage account with the same provider. Administrative costs of such a solution may similarly be high, as simple tasks like changing addresses may necessitate widespread maintenance of a large number of systems for the user. It is desirable to have a system that alleviated the above-referenced potential problems.